Cogito, ergo sum
Legacy:Building With Static Meshes
The introduction of Static Meshes has radically changed how maps are built. In the The Curse Of Static Meshes article, mappers explain their problems with this new technique. Here you'll find solutions.
Contents
Acclimatizing[edit]
rough thoughts to refactor:
- to get an idea of how to use SMs, use RMODE 3 in game, or Viewport Caption Context Menu -> Show -> Static meshes.
- despite what has been said, maps are not mere boxes with meshes: many maps still have a reasonably complex BSP, with things like subtracts for lowered floor areas (in the first map of the DD ladder)
Getting used to SM... some rough ideas:
- adapt DavidM's old advice about mapping for UT: copy. Take a UT2003 map you like – then rip it up and rip it off. Copy the style. Make corridors, entrances, walkways etc the same way as in that map. If you feel brave, load up the SM packages it uses and experiment with the other SMs in those packages.
Problems[edit]
Quick cures for static mesh ailments:
Finding the right mesh[edit]
Epic's mesh packages are notorious for being an absolute mess, with no logic to the way the meshes are organized. (Hello? 80% of meshes in "misc" group?)
Try our Static Mesh Package/Index. There's also an app being worked on that will let you search them by keyword.
Meshes stuck in maps[edit]
If you want to use any of the static meshes Epic's or Digital Extremes' mappers put into their maps' MyLevel packages, you do not have to re-import them into your own MyLevel package. Simply load the map they're in in the static mesh browser as if it was a static mesh package (in fact, since it contains static meshes, it's as good as one).
However, some players delete standard maps they do not like from their hard drive – mention the dependency in your map's accompanying text file.
PrePivot[edit]
Some meshes are always off-grid, no matter what you do to. This appears to be down to shoddy work on the part of Epic.
Use Display -> PrePivot to put awkward meshes back on grid.
Scaling Textures[edit]
SMs can be scaled to any size, which is great! But the texture they carry is scaled too, and sometimes this looks like crud if you make the mesh too large.
Create a TexScaler in MyLevel to rescale textures in a flash for static meshes you've scaled. For example, if you have doubled the size of the mesh, halved the size fo the texture to compensate.
Bad lights[edit]
A number of light meshes have the actual light part displaying a material that is set to unlit. You can find normal versions of the material if you look in the texture package it comes from, eg UCGeneric.
No back face[edit]
Meshes with no back face – eg the windows in DM-Oceanic.
You might have to put two meshes back to back, or create a two-side version of the material that is applied. Or use CSG brushes to fill in the gaps.
Customizing[edit]
See StaticMeshActor for useful properties that can be set to alter individual placed static meshes; see Static Mesh for properties of the actual resource that can be edited.
Briefly, you can change the following aspects of a placed mesh:
- size
- rotation
- displayed textures
Opinions on static mesh mapping[edit]
- The Curse Of Static Meshes – the curse
anything below here please refactor or delete!
Lee Perry (of Epic) writes on the Polycount Message Boards:
"Levels and environment meshes are far more my area of expertise. There's many factors that go into your frame rate of course, but it's normal to have about 30K to 60K polys *in view* at any time. Your level could have a great great GREAT deal more than than, it's all about what's visible, and there's many (easy to use) new tools to help with visibility, such as anti-portals and volumes.
For the most part we build level shells out of BSP at about 2-5 times the polys of a UT level, and then we populate it very densely with environment static meshes. These are built (most of the time) in a modular fashion, and pull a lot of the weight level textures used to in UT. Instead of slapping a texture on a wall, now you grab a couple of models and stick in front of the wall. The modular designs allow for a great deal of detail in a level without having to meticulously model a high-detail level. Building static mesh sets is pretty fun stuff, especially when you get the payoff of seeing them all over the web in everyone's levels, and largely used in ways you never would of expected.
You could model 2-3 basic walls (built with edges on a grid prederably), make a door, maybe a cieling piece or two, maybe 2 good decoration pieces if you feel like it, and voilà you'll have 9000 user maps using your prefabs everywhere they can fit them. It's cool to walk into a room you modeled, and not really recognize it because it was built so differently than you intended"
and
"Oh, BTW, for sea surfaces, you'd most likely drop in a dynamic water plane and it would be generated realistically in a way that should never tile. And you can set things like mesh resolution, wave height, etc... on that"
Source: Polycount Message Board
General Forum on Static Meshes[edit]
Amid cries that "Unreal Mapping is over", let's establish some rough ideas. First of all, people should realize that they're discussing based on suppositions.
Models may come to be treated much like textures are currently treated. That is:
- no-one complains that they can only use UT bundled textures,
- there's plenty of variety bundled with the game
- Epic mappers such as CliffyB have previously expressed surprise at the originality with which l33t community mappers use the built-in textures
- some people will specialize and create model packs, the same way people produced texture packs.
Model creating will become an extra job in the process of making environments; this is a natural direction to take since the complexity of the worlds is increasing.
Some more information taken from the Polycount message board (once again eepers stumps up the goods).
Lee Perry (of Epic) writes some more on the Polycount Message Boards:
Actually, Ent, the prefab modeling and level design questions are completely what I'm most familiar with, so no prob at all, ask away, detailed as you like!
No, nothing has replaced zones. They are still the best and fastest way to break up a map. Volume is a general term that could be anything from a damage volume to a volume that changes the physics within it. I imagine you're pretty much refering to "anti-portal volumes though (APV's if you will)"
An APV or simple Anti-portal sheet is something you use only when zoning won't do the trick for you. Rooms connected by hallways and so forth should still be zones, but if a room is really big with an object in the middle, you stick an APV in it, and it helps obscure things behind it (in the same zone). Another key use is in terrain. Say you've got a map with big hills on it. The whole outside is a single zone, but you don't wanna go drawing the whole world when you're outside. So you take an anti-portal and stick it in your major hills so the engine knows it doesn't need to draw things on the other side.
APVs can be any convex shape, preferably with low polys. Honestly I don't think once in the game has one been used that wasn't a simple cube though. it's not a big precision-mesh-fitting operation. Too many anti-portals start to outweigh the benefits of themselves as well, don't go dropping them in every little item just in case someone crouches behind it.
Naming areas can be done in Zone Infos, or a volume can be dragged over an area that does nothing but change the location name.
I don't know why anyone would claim APVs don't work in multiplayer, they're a key factor in getting maps running fast. They do.
Fog does occlude polys beyond it, yes. Unless a material specifically states it's double sided, the engine doesn't draw the backs of polys. It's still a good idea to delete polys you won't see, because there's still overhead with those polys as the engine runs around talking to the vid card trying to decide wether it needs to draw them or not.
Level polys vary a great deal, it's just one of many aspects you keep in mind. Overdraw from loads of particles have a big hit (learn to make efficient emitters!), some materials slow it, etc. But if you're just looking for a ballpark... 20K to 45K polys in view, onscreen, is pretty reasonable. As said before though, it varies widely. You can find cases where a test level pushes 600K polys at a steady 50 FPS, and you can find cases with loads of materials and overdraw and gameplay issues that runs 12K polys at 15FPS.
Luckily there are many tools in game that let you pull up stats and see exactly where your framerate is going as you run around a level, it's pretty easy to spot problem areas.
Source: Polycount Message Board
And heres some more fromthe same thread. Lee Perry is one patient guy.
"The way it works is this... if you're looking through an anti-portal and you see a little corner of a wall mesh sticking out behind it, the whole wall mesh gets drawn. If you move so as the whole thing is out of view, obscured by the volume, the whole mesh isn't drawn. So making a complicated volume for this use will generally not make it work better, you're always going to be moving around and seeing things around corners. It's best to use the simplest shape to get the job done."
Static Meshes and Collision[edit]
Here's some more fascinating information taken from the UT Modelling thread over at polycount (Props to Lee Perry again :)).
"Collision for static meshes is specified in the editor. Bullets and line-trace effects will default to per-polygon no-fuss collision. Player collision will too, but it's a good idea to make a simplified version in editor to reduce this, it gets expensive when you've got 16 people running around your area. That's an easy task, BTW, even though it sounds like a drag, Karma will benefit from that step anyway.
Karma collision *CAN* use per-poly collision, but it gets expensive quick. As with player collision, it's best to bring in your wall, build a relatively simplified BSP surface around it, and designate that as that object's collision. You only have to do that once. As you do that, every instance of that wall mesh throughout the level gains that same collision."
Also, if that's not something you're jazzed about, or you've got something that should really just be a cylinder or a box, in the little mesh browser you can create a collision mesh with like 2 clicks. They're called DOPs, and essentially you tell it which of the simple shapes you want and it shrink wraps that primative to your object. It's very fast, very user friendly, and it speeds up player and karma collision calculation VASTLY. BSP shells generally are only resorted to if a DOP shape isn't really appropriate.
By using these two collision techniques, there's really very few places you need to make any kind of blocking volumes."
Related Topics[edit]
- Static Mesh – Definition & basics
- Static Mesh Modeling – creating your own
- Static Mesh Package – listing of the default SM packages
- Hardware Brush
EntropicLqd: I've been thinking about this whole prefab thing and it occurs to me that in order to make effective use of the prefabs you will need to make your BSP/geometry corridors wider than you would expect. Otherwise when you add your "prefab wall" the interior space within your corridor (or room) will be smaller than anticipated. Some questions that could do with answering around this are:
- Do prefabs have a front and back (a side from which they are not visible)? It would seem a sensible.
- Should prefabs be algined with world geometry, or, do they need to sit slightly in front of the BSP'd wall (like in UT when you have 2 add brushes in the same place you see texture tears).
Mychaeel: You certainly can make prefabs that don't have a back side, and to achieve a 3D effect, they'll have to sit a bit in front of a wall.
Aphex: I presume meshes are treated the same way as our old friends semi-solids (though probably without the bsp errors ;) so you dont need to align them with anything, and they are separate from the BSP.
EntropicLqd: I pity the poor bugger that winds up refactoring all this information. I'd have a go but it scares me.
Flashman: Well sed Ent m8 :) btw: i'm currently making architecture that has no backfacing polys where I can guarantee there will be a wall/floor etc. It's just a matter of preference & performance :) apart from probs with texture alignment (probably my MAX un1337ness) the seem to go in fine!
